-
Notifications
You must be signed in to change notification settings - Fork 934
pwd: fix hostname resolution on macos #7029
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pwd: fix hostname resolution on macos #7029
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two quick thoughts:
- This is probably getting complicated enough to warrant a separate utility function (with tests), perhaps outside of the stream handler.
- I'm starting to feel like we should follow Kitty's example and treat the
file://
andkitty-report-cwd://
schemes differently: onlyfile://
URLs get the encoding. (See #7033)
100% agree, I had the same thought as I was working on this. I haven't confirmed the fix though so I figured I'd make a quick and dirty version that I could test, and clean it up later. And yep, that includes a separate function, tests, the whole thing 🙂
Yeah, we probably should. Or at the very least we probably shouldn't be using For example, |
It seems to me that this would be better solved on the macOS level. Either by using |
I think the main problem is that posix.gethostname() - the hostname we compare to whatever the shell integration passes to us - returns the mac address version of the hostname. I suppose we could run And either way I think we should treat mac addresses as valid hostnames, even if they're not compliant with the general linux hostname spec of |
Finally got to a place where I can reproduce it and recorded a video just to demonstrate: ghostty-bug.mp4 |
d372a1f
to
a3c7b3f
Compare
And now to demonstrate that the current set of changes work: ghostty-fix.mp4 |
I still need to clean up the code here more before this is ready. I'm thinking of creating some sort of utility function in It's way too late here to do that now though, so I'll pick this up again when I have the time, hopefully in the next week or so. |
b780820
to
f6d1718
Compare
@jparise I think this is ready for a proper review now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me but deferring to others who have more regular maintainership over these files.
When macOS's "Private WiFi address" feature is enabled it'll change the hostname to a mac address. Mac addresses look like URIs with a hostname and port component, e.g. 12:34:56:78:90:12 where `:12` looks like port 12. However, mac addresses can also contain letters a through f, so a valid mac address like ab:cd:ef:ab:cd:ef is valid, but will not be parsed as a URI, because `:ef` is not a valid port. This commit attempts to fix that by checking if the hostname is a valid mac address when `std.Uri.parse()` fails and constructing a new std.Uri struct using that information. It's not perfect, but is equally compliant with the URI spec as std.Uri currently is.
Also adds a test to verify that the function is working as intended.
we only need the mac-address-as-hostname workaround on macos, so we now have a comptime check to see if we're on macos.
d6b99a6
to
e4a175d
Compare
Sorry for the long response time here. I've rebased the branch on |
return std.Uri.parse(url) catch |e| { | ||
// The mac-address-as-hostname issue is specific to macOS so we just return an error if we | ||
// hit it on other platforms. | ||
if (comptime builtin.os.tag != .macos) return e; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jparise I changed this from comptime if (…
to if (comptime …
to fix the build failure on non macOS systems, but I'm not familiar enough with Zig's comptime to know if it makes sense to even keep the comptime
check in here? Should we just remove it, or does it still make sense to keep it? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In its current state, I don't think we need to gate this on macOS. It's done in a generic way, although it would be good to get some real-world confirmation that this all makes sense on other platforms (e.g. no false positives/negatives).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a very simple test run in a Fedora VM and this seemed to be working correctly. It was the same thing I did in #7029 (comment) to confirm this was was working correctly. Super simple test so I'm not sure if we want something more thorough.
Anything I can do here to help with testing this on other platforms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely no clue
Description
Yet another edge case in #2484
When macOS's "Private WiFi address" feature is enabled it'll change the hostname to a mac address. Mac addresses look like URIs with a hostname and port component, e.g.
12:34:56:78:90:12
where:12
looks like port12
. However, mac addresses use hex numbers and as such can also contain lettersa
throughf
. So, a mac address likeab:cd:ef:ab:cd:ef
is valid, but will not be parsed as a URI, because:ef
is not a valid port.This commit attempts to fix that by checking if the hostname is a valid mac address when
std.Uri.parse()
fails and constructing a newstd.Uri
struct using that information.It's not perfect, but is equally compliant with the URI spec as
std.Uri
currently is. Meaning not at all compliant 😅Testing instructions
Unit tests
Important
I don't know if these tests are run in CI or if they're picked up by
zig build test
. I get an unrelated crash that mentionsminidump
and an invalid OSC command when I try to runzig build test
on my mac.zig test src/os/hostname.zig
is passing.Manual testing instructions
Setup - Enable the "Private WiFi address" setting
Important
You must be connected to WiFi to be able to test this.
Rotating
.Important
Now you wait. The private Wi-Fi address will eventually rotate to a mac address that ends with a non-digit, e.g.
0a
,ff
,e2
, etc. You'll notice this when your shell integration stops working, e.g. you open a new tab in Ghostty and the shell is in your home directory instead of whichever directory you had open in your previous tab.Testing the changes
cd
to any directory that isn't the default (usually$HOME
) directory, e.g.cd Documents
.main
: land in$HOME
in the new tab or split.